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Scope 



The present document describes the stage three protocol for basic communication procedures common to several 
services when at least one Application Server (AS) is included in the communication. The common procedures are 
based on stage three specifications for services. 

The present document contains examples of signalling flows for the common basic communication procedures. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI ES 283 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 
[3GPP TS 24.229 [Release 7], modified]". 

[2] Void. 

[3] Void. 

[4] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[5] IETF RFC 3262: "Reliability of Provisional Responses in the Session Initiation Protocol (SIP)". 

[6] IETF RFC 3960: "Early Media and Ringing Tone Generation in the Session Initiation Protocol 

(SIP)". 

[7] ETSI TS 181 005: "Telecommunications and Internet Converged Services and Protocols for 

Advanced Networking (TISPAN); Service and Capability Requirements". 
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[8] ETSI ES 282 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Resource and Admission Control Sub-system (RACS); 
Functional Architecture" . 

[9] ETSI ES 283 027: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Endorsement of the SIP-ISUP Interworking between the 
IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks 
[3GPP TS 29.163 (Release 7), modified]". 

[10] Void. 

[11] ITU-T Recommendation 1. 1 12: "Vocabulary of terms for ISDNs" . 

[12] IETF RFC 5009: "Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for 

Authorization of Early Media" . 

[13] IETF RFC 35 1 5 : "The Session Initiation Protocol (SIP) Refer Method" . 

[14] IETF RFC 3725: "Best Current Practices for Third Party Call Control (3pcc) in the Session 

Initiation Protocol (SIP)". 

[15] ETSI TS 183 007: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN simulation services; Originating Identification 
Presentation (OIP) and Originating Identification Restriction (OIR); Protocol specification". 

2.2 Informative references 

[16] ETSI TR 180 000: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Terminology". 



3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 180 000 [16] and the following apply: 

announcement: service related message sent to a user that can be of any type of media e.g. a voice message or a 
video-clip 

communication: transfer of information between two or more users, entities, processes or nodes according to some 
agreed conventions 

NOTE: See ITU-T Recommendation I.l 12 modified [11]. 

early media: media sent before a communication is established 

in-band announcement: announcement sent by the network using the bearer established for a communication 

Incoming Media Gateway Control Function (IMGCF): MGCF that terminates incoming calls from IMS and 
originates call the BICC/ISUP protocols 

Originating Application Server (O-AS): controlling application server responsible for the services provided to the 
originating user 

Outgoing Media Gateway Control Function (O-MGCF): MGCF that terminates incoming calls using BICC/ISUP 
protocols and originates calls to IMS 

Terminating Application Server (T-AS): controlling application server responsible for the services provided to the 
terminating user 
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3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

Spec 3^*^ party call control 

ACR Automatic Call Rejection 

AS Application Server 

B2BUA Back-to-Back User Agent 

IBCF Interconnection Border Control Function 

I-CSCF Interrogating Call Session Control Function 

IFC Initial Filter Criteria 

I-MGCF Incoming Media Gateway Control Function 

IMS IP Multimedia Subsystem 

ISDN Integrated Services Digital Network 

MGCF Media Gateway Control Function 

MGW Media GateWay 

MRFC Media Resource Function Controller 

MRFP Media Resource Function Processors 

NDUB Network Determined User Busy 

NGN Next Generation Network 

0-AS Originating Application Server 

0-MGCF Outgoing Media Gateway Control Function 

P-CSCF Proxy Call Session Control Function 

PSTN PubHc Switched Telephone Network 

S-CSCF Serving Call Session Control Function 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

T-AS Terminating Application Server 

T-MGF Trunking Media Gateway Function 

UDUB User Determined User Busy 

UE User Equipment 

URL Uniform Resource Locator 



Common basic communication procedures 



4.1 



Introduction 



Services may need to send announcements for example to explain the reason for rejecting a communication request or 
to report the progress of a communication request. The announcement may be of any type of media e.g. an audio 
announcement or a video clip. Clause 4.2 describes the announcement common procedure and annex A shows examples 
of signalling flows for some announcement scenarios. 

Some services are triggered by a user's busy condition e.g. the Communication Forwarding on Busy service. The busy 
condition may be determined by the network i.e. the Network Determine User Busy (NDUB) condition or by the user 
i.e. the User Determine User Busy (UDUB) condition. Clause 4.4 describes the network determine user busy common 
procedure and the annex B shows examples of signalling flows for some busy scenarios. 

Some services are triggered by sending a REFER request, for example Explicit Communication Transfer. A receiver of 
the REFER request in some cases might not be able to process the REFER request. Clause 4.4a describes fallback 
procedures to 3^^ party call control. Annex E provides some examples for signalling flows. 
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4.2 Announcement 

4.2.1 General 

Announcements may be sent during the establishment of a communication session, when rejecting a communication 
request, during an estabHshed communication session or during the release of a communication session. 

4.2.2 Providing announcements to a user during the establishment of a 
communication session 

A service may provide an announcement during the establishment of a communication. If an announcement is provided 
the service shall use one of the following methods: 

• use an Call-Info header field in the INVITE request; or 

• use an Call-Info header field in the 1 80 (Ringing) response to the INVITE request; or 

• use early media as defined by RFC 3960 [6] and using the P-Early-Media header field authorizing early media 
as defined in RFC 5009 [12] for the gateway model; or 

• use multiple early dialogs as described in annex D and using the P-Early-Media header field authorizing early 
media as defined in RFC 5009 [12]. 

4.2.3 Providing announcements to a user during an established 
communication session 

A service may provide an announcement during an established communication. If an announcement is provided the 
service shall use one of the following methods: 

• use an Call-Info header field in a re-INVITE request; or 

• use the existing media stream. The media stream may have to be re-negotiated by the service to a media type 
suitable for the announcement. 

Mixing announcements into an existing media stream requires that the AS use the 3^*^ party call control procedure as 
specified by clause 5.7.5 in ES 283 003 [1]. 

4.2.4 Communication request rejected by AS 

A service may provide an announcement when rejecting a communication request e.g. in order to explain the reason for 
rejecting the communication request in more detail. If an announcement is provided the service shall: 

• use an Error-Info header field in the 3xx, 4xx, 5xx or 6xx response to the INVITE request; or 

• use early media for sending the announcement in-band as defined by RFC 3960 [6] and using the P-Early- 
Media header field authorizing early media as defined in RFC 5009 [12] for the gateway model_and insert the 
Reason Header with the proper cause value; or 

• use early media for sending the announcement in-band in an early dialog as described in annex D and using 
the P-Early-Media header field authorizing early media as defined in RFC 5009 [12] and insert the Reason 
Header with the proper cause value; or 

• accept the communication request and use the established session for sending an in-band announcement. 

If the announcement terminates before the originating user releases, then the AS sends a 487 to end the session and the 
dialog with the originating user. 
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4.2.5 Providing announcements to a user during the release of a 
communication session 

A service may provide an announcement to the UE, who does not end the session, during the release of a 
communication, in order to, e.g. tell the charge information. If an announcement is provided the service shall: 

• use the existing media stream. The media stream may have to be re-negotiated by the service to a media type 
suitable for the announcement; or 

• change to new media for sending the announcement. 

4.3 Alternative ring tone 

A service may provide an alternative ring tone using the Alert-Info header field as specified by RFC 3261 [4]. 

The intention with this alternative ring tone is to override local ring tones provided by the UE. It is recommended that 
the size of the referenced alternative ring tone is small in order not to delay communication establishment. 

4.4 Network Determined User Busy (NDUB) 

Deployment of some service may require the support of the optional service requirements for "network determined user 
busy" and "approaching network determined user busy" defined in TS 181 005 [7]. In order to support such 
requirements it is assumed that a network function/application server is deployed to track a user's busy condition status 
from the perspective of the network. 

The present document is applicable only in cases whereby the network operator has complete knowledge of the 
applications to which an end user has subscribed and assumes that those applications will furnish the network entity 
responsible for tracking "busy condition" with appropriate information to enable this determination to be made. This 
may require appropriate business arrangements between the network operator and the application provider. 

NOTE: In the context of NGN release 2 there is no scope for tracking bandwidth availability in the customer 
network (see ES 282 003 [8]). As such it is possible that a communication could be presented based on 
the network entity determining that the communication can be presented when in fact congestion in the 
customer network will prevent the communication being presented. This is a limitation of the present 
document in release 2. 

Determination of "network determined user busy" by the network may restrict the ability to deploy and support end user 
devices which perform local services based on "user determined user busy" as part of their base functionality. 

4.4a Special REFER request handling procedures 

After the reception of a REFER request the AS may start Spec procedures under the following conditions: 

• the Application Server acts as a B2BUA, so the AS has knowledge about the existing partial dialogs it is 
involved in, especially of the media user for this communication; and 

• the REFER request is routed via this AS. 

The Spec procedures shall be achieved by sending re-INVITE requests in existing partial dialogs and by sending 
INVITE requests to establish new partial dialogs. 

Tables 1 and 2 give decision criteria when to start Spec procedures. 
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Table 1 : Terminating party of a communication sends a REFER request 



Content of the Allow header in the 
initial INVITE from A->B 


Action AS-B on the REFER from B 


Action that the AS-B does on the 
initial INVITE 


INVITE with Allow header with no 
REFER token 


Invoke the Spec procedure directly 


AS-B adds the REFER token to the 
Allow header 


INVITE with Allow header with a 
REFER token 


Forward the REFER and if the 403 or 
501 response is received, fall back to 
Spec procedure 


No modification needed in the Allow 
header 


INVITE without Allow header 


Forward the REFER and if the 403 or 
501 response is received, fall back to 
Spec procedure 


No modification needed in the INVITE 



Table 2: Originating party of a communication sends a REFER request 



Content of the Allow header in the 

200 OK response on the initial 

INVITE (A->B dialog) 


Action AS-A on the REFER from A 


Action that the AS-A does on the 
200 OK response on A-B dialog 


200 (OK) with Allow header with no 
REFER token 


Invoke the Spec procedure directly 


AS-A adds the REFER token to the 
Allow header 


200 (OK) with Allow header with a 
REFER token 


Forward the REFER and if the 403 or 
501 response is received, fall back to 
Spec procedure 


No modification needed in the Allow 
header 


200 (OK) response without Allow 
header 


Forward the REFER and if the 403 or 
501 response is received, fall back to 
Spec procedure 


No modification needed in the 200 
(OK) response 



As a network option, an AS of the initiator of the REFER request that has prior knowledge that the remote party is not 
allowed to receive or does not support the REFER method, may initiate 3^*^ party call control procedures directly. 

To avoid a longer re-negotiation of the media, the media information of the existing partial dialogs are used for the 
INVITE requests or the first re-INVITE requests during the Spec procedures. 



4.5 Operational requirements 



4.5.1 



Provision/withdrawn 



No special requirements for provision/withdrawn. Any requirements on provision/withdrawn belong to the service 
using the common basic procedures specified by the present document. 

4.5.2 Requirements on the originating network side 

Void. 

4.5.3 Requirements on the terminating network side 

Void. 

4.6 Coding requirements 

The syntax for the relevant headers in the SIP requests and SIP responses shall be as follows: 

• The syntax of the Alert-Info header field conforms to the requirements in ES 283 003 [1] and RFC 3261 [4]. 

• The syntax of the Error-Info header field conforms to the requirements in ES 283 003 [1] and RFC 3261 [4]. 

• The syntax of the Call-Info header field conforms to the requirements in ES 283 003 [1] and RFC 3261 [4]. 

• The syntax of the P-Early-Media header field is described in RFC 5009 [12]. 
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• The syntax of the Allow header field conforms to the requirements in ES 283 003 [1] and RFC 3261 [4]. 

4.7 Signalling procedures 

4.7.1 Activation, deactivation and registration 

There are no procedures for activation, deactivation or registration defined. 

4.7.2 Invocation and operation 

4.7.2.1 Actions at the originating UE 

Procedures according to ES 283 003 [1] shall apply. 

Certain services require the usage of the Alert-Info header field, Call-Info header field and Error-Info header field 
according to procedures specified by RFC 3261 [4]. 

If the UE detects that in-band information is received from the network as early media, the in-band information received 
from the network shall override locally generated communication progress information. 

4.7.2.2 Actions at the originating P-CSCF 

Procedures according to ES 283 003 [1] shall apply. 

The P-CSCF may have a local policy to remove an Error-Info header field, Call-Info header field and/or an Alert-Info 
header field. 

4.7.2.3 Actions at the S-CSCF serving the originating user 

Procedures according to ES 283 003 [1] shall apply. 

4.7.2.4 Actions at the incoming l-CSCF 

Procedures according to ES 283 003 [1] shall apply. 

4.7.2.5 Actions at the outgoing IBCF 

Procedures according to ES 283 003 [1] shall apply. 

The IBCF may have a local policy to remove an Error-Info header field, Call-Info header field and/or an Alert-Info 
header field. 

4.7.2.6 Actions at the incoming IBCF 

Procedures according to ES 283 003 [1] shall apply. 

The IBCF may have a local policy to remove an Error-Info header field, Call-Info header field and/or an Alert-Info 
header field. 

4.7.2.7 Actions at the destination P-CSCF 

Procedures according to ES 283 003 [1] shall apply. 

The P-CSCF may have a local policy to remove an Error-Info header field, Call-Info header field and/or an Alert-Info 
header field. 
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4.7.2.8 Actions at the S-CSCF serving the terminating UE 

Procedures according to ES 283 003 [1] shall apply. 

4.7.2.9 Actions at the AS 

The procedures in this clause apply for the AS serving the originating UE and the AS serving the terminating UE. 

4.7.2.9.1 Providing announcements during an established communication session 

Services may use the Call-Info header field according to procedures specified by RFC 3261 [4] to provide an 
announcement during an established communication session. 

Services may send an in-band message or media using an existing media-stream to provide an announcement during an 
established communication session. 

4.7.2.9.2 Providing announcements during the establishment of a communication session 

The AS may use the Call-Info header field according to procedures specified by RFC 3261 [4] in order to provide an 
announcement or an alternative ring tone as specified in clause 4.7.9.4 during the establishment of a communication 
session. 

The AS may use the MRFC and the MRFP to send an in-band announcement using early media according to the rules 
and procedures of the RFC 3261 [4], RFC 3262 [5], RFC 3960 [6] and RFC 5009 [12]. 

4.7.2.9.3 Providing announcements when communication request is rejected by the AS 

The AS may use the Error-Info header field according to procedures specified by RFC 3261 [4] in order to provide an 
announcement when the establishment of a communication session is rejected. 

The AS may use the MRFC and MRFP to send an in-band announcement using early media according to the rules and 
procedures of the RFC 3261 [4], RFC 3262 [5], RFC 3960 [6] and RFC 5009 [12]. 

4.7.2.9.4 Providing alternative ring tone during the establishment of a communication 
session 

The AS may use the Alert-Info header field according to procedures specified by RFC 3261 [4] in order to provide an 
alternative ring tone during the establishment of a communication session. 

4.7.2.9.5 Early dialog procedures at the AS 

The procedures for dealing with early dialog established between the AS and the originating UE is described in 
annex D. 

4.7.2.9.6 Providing announcements during the release of a communication session 

Services may send an in-band message or media using an existing media-stream or changing to new media-stream to 
provide an announcement during the release of a communication session. 
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4.7.2.9.7 Starting special REFER handling procedures at the AS of the initiator of the 

REFER request 

4.7.2.9.7.1 REFER is sent inside a dialog 

4.7.2.9.7.1 .1 Normal procedures 

If the AS receives a 403 Forbidden or a 501 Not implemented in response to a REFER request forwarded by the AS, it 
shall send a 202 Accepted response followed by a NOTIFY request with a 100 Trying status line to the originator of the 
REFER request, according to the procedures of RFC 3515 [13]. 

The AS then shall perform third party call control procedures according to Flow III or Flow IV of RFC 3725 [14], with 
the following additions and clarifications. 

The AS should verify if it is involved in the dialogs between the originator of the REFER on the one side and the 
REFER target and the Refer- to target on the other side. 

Then the AS shall send an INVITE request to the Refer-to target if it is not involved in a dialog with the Refer-to target 
(e.g. Blind ECT), or the AS shall send a re-INVITE request to the Refer-to target if it is involved in a dialog with the 
Refer-to target (e.g. Consultative ECT). The INVITE request shall contain if available a P-Asserted-ID header field 
with a valid identity of the REFER target and a Referred-by header field matching the P-Asserted-Identity of the 
REFER request. When including the P-Asserted-Identity the AS shall also include the Privacy headers obtained from 
the Request or Response in which this P-Asserted-Identity was obtained. 

When the partial dialog with the Refer-to target is acknowledged following a 200 OK, the AS shall send in the original 
partial dialog a NOTIFY request with a 100 Trying status line to the originator of the REFER request, according to the 
procedures of RFC 3515 [13]. After that the AS shall send a re-INVITE request to the REFER target. The re-INVITE 
request shall contain if available a P-Asserted-ID header field with a valid identity of the REFER-to target and a 
Referred-by header field matching the P-Asserted-Identity of the REFER request. 

When the partial dialog with the REFER target is acknowledged following a 200 OK, the AS shall send in the original 
partial dialog a NOTIFY request with a 200 OK status line to the originator of the REFER request, according to the 
procedures of RFC 3515 [13]. If a Replaces parameter is included in the Refer-To header field of the original REFER 
request and it refers to the original partial dialog between the referrer and the refer-to target, the AS shall send a BYE 
request in the original partial dialog to the referrer. 

When the 3^*^ party call control procedures were successful, continued processing procedures according to clause 7 of 
RFC 3725 [14] shall be applied. 

As a network option, the AS could send a 202 Accepted response directly and initiate 3^^ party call control procedures 
without trying to forward the REFER request to the REFER target. 

NOTE 1 : For example, when UE-A and UE-B establish a session, they will exchange their own capabilities for SIP 
methods by using "Allow" header. If the AS lies in the signalling path between UE-A and UE-B, it knows 
whether the two UEs support REFER or not, and can initiate 3^*^ party call control procedures. Another 
example is that a network operator does not want to send REFERs to a user because of security reasons. 

NOTE 2: The AS can enforce OIR privacy settings on OIR relevant headers carried in the generated INVITE 

and/or re-INVITE requests, as specified TS 183 007 [15] for regular INVITE requests originated by the 
served user. 

NOTE 3: The AS can generate charging events for the generated INVITE requests, correlated to the initiator of the 
REFER request. 

4.7.2.9.7.1 .2 Exceptional procedures 

If the 3^^ party call control procedures fail because a media negotiation between REFER target and Refer-to target is not 
possible (e. g. the codes cannot be negotiated or the offered ports have changed in a subsequent SDP offer), or 
REFER target or Refer-to target answer the INVITE request with an error response, error handling procedures 
according to clause 6 of RFC 3725 [14] shall be applied. Additionally the AS shall send a NOTIFY for terminating the 
original REFER request. 
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4.7.2.9.7.2 REFER is sent outside a dialog 

4.7.2.9.7.2.1 Normal procedures 

If the AS receives a 403 Forbidden or a 501 Not implemented in response to a REFER request forwarded by the AS, it 
shall send a 202 Accepted response followed by a NOTIFY request with a 100 Trying status line to the originator of the 
REFER request, according to the procedures of RFC 3515 [13]. 

The AS then shall perform third party call control procedures according to Flow III or Flow IV of RFC 3725 [14], with 
the following additions and clarifications: 

The AS shall send an INVITE request to the Refer-to target. The INVITE request shall contain if available a 
P-Asserted-ID header field with a valid identity of the REFER target and a Referred-by header field matching the 
P-Asserted-Identity of the REFER request. 

When the dialog with the Refer-to target is acknowledged following a 200 OK, the AS shall send in the REFER dialog 
a NOTIFY request with a 100 Trying status line to the originator of the REFER request, according to the procedures of 
RFC 3515 [13]. After that the AS shall send an INVITE request to the REFER target. The INVITE request shall contain 
if available a P-Asserted-ID header field with a valid identity of the Refer-to target and a Referred-by header field 
matching the P-Asserted-Identity of the REFER request. When including the P-Asserted-Identity the AS shall also 
include the Privacy headers obtained from the Request or Response in which this P-Asserted-Identity was obtained. 

When the dialog with the REFER target is acknowledged following a 200 OK, the AS shall send in the REFER dialog a 
NOTIFY request with a 200 OK status line to the originator of the REFER request, according to the procedures of 
RFC 3515 [13]. 

When the 3^^ party call control procedures were successful, continued processing procedures according to clause 7 of 
RFC 3725 [14] shall be applied. 

As a network option, the AS could send a 202 Accepted response directly and initiate 3^^ party call control procedures 
without trying to forward the REFER request to the REFER target. 

NOTE 1 : For example, when UE-A and UE-B establish a session, they will exchange their own capabilities for SIP 
methods by using "Allow" header. If the AS lies in the signalling path between UE-A and UE-B, it knows 
whether the two UEs support REFER or not, and can initiate 3^*^ party call control procedures. Another 
example is that a network operator does not want to send REFERs to a user because of security reasons. 

NOTE 2: The AS can enforce OIR privacy settings on OIR relevant headers carried in the generated INVITE 

and/or re-INVITE requests, as specified TS 183 007 [15] for regular INVITE requests originated by the 
served user. 

NOTE 3: The AS can generate charging events for the generated INVITE requests, correlated to the initiator of the 
REFER request. 

4.7.2.9.7.2.2 Exceptional procedures 

If the 3^^ party call control procedures fail because a media negotiation between REFER target and Refer-to target is not 
possible, or REFER target or Refer-to target answer the INVITE request with an error response, error handling 
procedures according to clause 6 of RFC 3725 [14] shall be applied. Additionally the AS shall send a NOTIFY for 
terminating the original REFER request. 

4.7.2.10 Action at the terminating UE 

Certain services require the usage of the Alert-Info header field and Call-Info header field according to procedures 
specified by RFC 3261 [4]. 
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4.8 Interactions with otiier networks 

4.8.1 Interaction with PSTN/ISDN 

When a 1 80 (Ringing) response is received containing an Alert-Info header field the 0-MGCF can instruct the T-MGF 
to play out early media available at the associated URL, to the PSTN leg of the communication. The interaction with 
PSTN/ISDN is described in ES 283 027 [9]. 

When a 3xx, 4xx, 5xx or 6xx SIP response to an INVITE request is received from the network containing an Error-Info 
header field, the 0-MGCF can instruct the T-MGF to play out media available at the associated URL, towards PSTN. 

When a relNVITE request is received from the network containing a Call-Info header field the MGCF can instruct the 
MGW to transport media available at the associated URL, to the PSTN leg of the communication. 

An I-MGCF may as a network option generate a Call-Info header field, an Alert-Info header field or an Error-Info 
header field according to rules and procedures of RFC 3261 [4] to provide media instead of the in-band media received 
from the PSTN. 

When a 183 (Session Progress) response is received the 0-MGCF sends an appropriate message towards the 
PSTN/ISDN including an indication that in-band information is available. The interaction with PSTN/ISDN is 
described in ES 283 027 [9]. 

The 0-MGCF authorizes early media as specified in RFC 5009 [12]. If early media is authorized the 0-MGCF indicates 
that in-band information is available towards the PSTN/ISDN. The interaction with PSTN/ISDN is described in 
ES 283 027 [9]. 

The I-MGCF can include a P-Early-Media header field when in-band information is received from the PSTN/ISDN as 
specified in the RFC 5009 [12]. 

4.8.2 Interworking with PSTN/ISDN Emulation 

When a 1 80 (Ringing) response is received containing an Alert-Info header field the 0-MGCF can instruct the T-MGF 
to play out early media available at the associated URL, to the PSTN/ISDN Emulation leg of the communication. 

When a 3xx, 4xx, 5xx or 6xx SIP response to an INVITE request is received from the network containing an Error-Info 
header field, the 0-MGCF can instruct the T-MGF to play out media available at the associated URL, to the 
PSTN/ISDN Emulation side of the communication. 

When a re INVITE request is received from the network containing a Call-Info header field the PSTN/ISDN Emulation 
Subsystem can instruct the T-MGF to transport media available at the associated URL, to the PSTN/ISDN Emulation 
leg of the communication. 

A PSTN/ISDN Emulation subsystem may as a network option generate a Call-Info header field, an Alert-Info header 
field or an Error-Info header field according to rules and procedures of RFC 3261 [4] to provide media instead of the 
in-band media received from the PSTN/ISDN Emulation subsystem. 

The PSTN/ISDN Emulation subsystem authorizes early media as specified in RFC 5009 [12]. 

The PSTN/ISDN Emulation subsystem can include a P-Early-Media header field when in-band information is received 
from the PSTN/ISDN as specified in the RFC 5009 [12]. 

4.8.3 Interaction with external IP network 

Depending on the external IP network and message direction, IBCF may have a local policy to remove an Error-Info 
header field, Call-Info header field and/or an Alert-Info header field. 

4.9 Signalling flows 

Signalling flows are documented in annexes A and B. 
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4.1 Parameter values (timers) 

No specific timers are needed. 
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Annex A (informative): 

Signalling flows for announcements 

This annex shows some example signalHng flows for the procedures described in clause 4.1. 

A.1 Providing announcements to a user during the 
establishment of a communication session 

A.1 .1 Providing in-band announcement 

This clause shows an example signalling flow of how an AS can send an announcement to the calling user during the 
establishment of a communication. 

Separate dialogs are established between the origination UE and the AS controlling the announcement, and the 
originating UE and the terminating UE. It is allowed that a different SDP answer is sent in the 200 (OK) response from 
the terminating UE than the SDP answer that was previously sent from the AS in the 183 (Session progress) response. 

The AS can e.g. be the AS serving the calling party or the AS serving a called party and may apply for example when a 
communication is going to be diverted and the AS serving the diverting user inform the calling party that the 
communication is going to be diverted. 
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Figure A.l shows the signalHng flow for the scenario. 
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NOTE: The called party may return provisional responses to the INVITE request. However, for simplicity those 
responses are left out. 

Figure A.l : Announcement started during the establishment of a communication 

The calling party initiates a communication by means of an INVITE request. The INVITE request is forwarded toward 
the called party. 
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Along the signalling path, created by the INVITE request, some service logic in an Application Server (AS) wants to 
send an announcement towards the calling party. 

The flow is based on the assumptions that the Supported header field includes the option-tag "lOOrel". 

The steps of the signalling flow are as follows: 

1) S-CSCF receives an INVITE request. 

2) S-CSCF sends the 100 (Trying) response towards to sender of the INVITE request. 

3) S-CSCF evaluates the initial Filter Criteria. 

4) S-CSCF sends the INVITE request to the AS. 

5) The AS sends the 100 (Trying) to S-CSCF. 

6) Service logic in the AS decides to send an announcement to the calling party. 

7) The MRFC interacts with the MRFP in order to reserve resources for the announcement. As part of the 
interaction with MRFP the AS receives the necessary media parameters e.g. IP address and port numbers and 
provide the IP address and port number for the calling party to the MRFP. 

8) The AS sends a 183 (Session progress) response to S-CSCF. 
The response includes: 

a) an answer to the SDP received in the INVITE request; 

b) a P-Early-Media header field set to "sendonly"; and 

c) the Require header field set to " lOOrel" . 

9) S-CSCF sends the 183 (Session progress) response towards the calling party. 
S-CSCF receives a PRACK request. 
S-CSCF sends the PRACK request to the AS. 
The AS sends a 200 (OK) to the PRACK request to S-CSCF. 
S-CSCF sends the 200 (OK) towards the calling party. 
The MRFC interacts with the MRFP in order to start the announcement. 
The MRFP sends the announcement towards the calling party. 
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The complete announcement is sent and the MRFP interacts with the AS/MRFC in order to inform that the 
announcement is terminated. 

The MRFC interacts with the MRFP in order to release the resources used for the announcement. 

The AS sends the INVTE request towards the called party. The INVITE request contains the same information 
as the INVITE request received in step 4 with the modification done by AS according to rules and procedures 
of DES TISPAN-ES 283 003 [1]. 

S-CSCF sends the 100 (Trying) response to the AS. 

S-CSCF sends the INVITE request towards the called party. 

S-CSCF receives a 100 (Trying) response. 

S-CSCF receives a 200 (OK) response to the INVITE request. 

S-CSCF sends the 200 (OK) response to the INVITE request to the AS. 

The AS sends the 200 (OK) response to the INVITE request to the S-CSCF. 

S-CSCF sends the 200 (OK) response to the INVITE request towards the calling party. 
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26) S-CSCF receives an ACK request. 

27) S-CSCF sends the ACK request to the AS. 

28) The AS sends the ACK request to S-CSCF. 

29) S-CSCF sends the ACK towards the called party. 

When the UE of the calling party receives the 200 (OK) response to the INVITE request the UE can regard the early 
dialog created for the announcement between the UE and the AS terminated. 

A.1.2 Including Alert-Info header field in the 180 (Ringing) 
response 

RFC 3261 [4] specifies the Alert-Info header field as a means to indicate a source of media to play an alternative ring 
tone by an originating endpoint. 

An example of this mechanism is shown in figure A.2. 
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NOTE: In the figure the SDP signalling details to establish media are not shown for simplicity. 
Figure A.2: Alert-Info header field in the 180 (Ringing) response to indicate an alternative ring tone 
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The steps of the flow are as follows: 



1) S-CSCF receives an INVITE request from the originating user. The originating user may be a user served 
by this S-CSCF, a user served by another S-CSCF or a user connected to PSTN/ISDN via a MGCF. 

2) S-CSCF sends a 100 (Trying) response. 

3) S-CSCF evaluates the Initial Filter Criteria. 

4) S-CSCF sends the INVITE request to the AS. 

5) The AS sends a 100 (Trying) response to S-CSCF. 

6) The AS sends the INVITE request to S-CSCF. 

7) S-CSCF sends the 100 (Trying) response to the AS. 

8) S-CSCF sends the INVITE request towards the called party. The called party may be a user served by 
another S-CSCF or a user connected to PSTN/ISDN via a MGCF. 

9) S-CSCF receives a 100 (Trying) response. 

10) S-CSCF receives a 180 (Ringing) response. 

11) S-CSCF sends the 180 (Ringing) response to the AS. 

12) The AS inserts a valid Alert-Info header field in the 180 (Ringing) including a URL to a media file 
containing the appropriate tone and sends the 180 (Ringing) response to S-CSCF. 

EXAMPLE: This file http://operator.net/tone.wav , in the picture abbreviated to http://url.wav is played at the 
originating UE (step 14). 

13) S-CSCF sends the 180 (Ringing) response towards the originating user. 

14) The http://url.wav (for example http://operator.net/tone.wav) is retrieved and played at the originating 
user. 

15-18) S-CSCF receives a 200 (OK) response to the INVITE request and forwards it to the originating user via 
the AS. 

19) The originating user stops playing the tone. 

20-23) S-CSCF receives an ACK request and forwards it towards the called party via the AS. 

A.1 .3 Announcements provided by the PSTN/ISDN 

This clause shows the signalling flow for a scenario where a user connected to the IP network establish a 
communication with a user connected to the PSTN/ISDN. During the establishment of the communication the 
PSTN/ISDN provides an announcement e.g. "The communication is forwarded" or "The user is not reachable". 
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Figure A. 3 shows the signalHng flow for the scenario. 
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NOTE: The flow assumes the use of the option-tag "lOOrel" defined in RFC 3262 [5] other scenarios may also 
apply. T-MGF is left out of the figure for simplicity. 

Figure A.3: Announcement provided by PSTN/ISDN during the establishment of a communication 

The steps of the flow are as follows: 

1) The MGCF receives an INVITE request from the IP network. The request includes an SDP offer. 

2) The MGCF sends a 100 (Trying) response to the IP network. 

3) The MGCF sends an lAM towards PSTN. 

4) The MGCF receives an early ACM from the PSTN/ISDN with an indication that "In-band information may be 
available". 

5) The MGCF sends a 183 (Session Progress) response to the IP network. 
The response includes: 

a) the answer to the SDP offer received in the INVITE request; 

b) A P-Early-Media header field set to "sendonly"; and 

c) The option-tag " lOOrel" in the Require header. 

6) The MGCF receives the PRACK request. 

7) The MGCF sends a 200 (OK) response to the PRACK request. 

8) The T-MGF sends the in-band announcement received from the PSTN/ISDN to the IP network. 



ETSI 



24 



ETSI TS 183 028 V2.4.0 (2008-01) 



Depending on the reason for the announcement the establishment of the communication continues or the estabUshment 
of the communication is aborted. 

A.1 .4 Announcement provided towards a user connected to the 
PSTN/ISDN 

This clause shows an example signalling flow for a scenario where a user in PSTN/ISDN establishes a communication 
with a user connected to IMS. During the establishment an AS in the IP network provides an announcement, 
e.g. "The communication is forwarded" or "The user is not reachable". 

Figure A.4 shows the signalling flow for the scenario. 
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NOTE: The flow assumes the use of the option-tag "lOOrel" defined in RFC 3262 [5] other scenarios may also 
apply. T-MGF is left out of the figure for simplicity. 

Figure A.4: Announcement provided towards a user connected to PSTN/ISDN 
during establishment of a communication 

The steps of the flow are as follows: 

1 ) The MGCF receives an I AM from the PSTN/ISDN. 

2) The MGCF sends an INVITE request to the IP network. The request includes a SDP offer. 

3) The MGCF receives a 100 (Trying) response from the IP network. 

4) The MGCF receives a 183 (Session Progress) response from the IP network. 
The response includes: 

a) the answer to the SDP offer sent in the INVITE request; 

b) a P-Early-Media header field set to "sendonly"; and 

c) the option-tag " lOOrel" in the Require header field. 
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5) The MGCF sends a PRACK request towards the IP network. 

6) The MGCF sends an early ACM to the PSTN/ISDN. The early ACM contains the "in-band information may 
be available" indication. 

7) The MGCF receives a 200 (OK) response to the PRACK request. 

8) The T-MGF receives the in-band announcement from the IP network and forwards the announcement to the 
PSTN/ISDN network. 

Depending on the reason for the announcement the establishment of the communication continues or the establishment 
of the communication is aborted. 



A.2 Providing announcements to a user during an 
established communication 

The way an announcement is sent to a user during an established communication depends on the scenario and the 
importance of the announcement. 

The following scenarios exist: 

• scenario 1: two users are communicating with (at least) one AS in the signalling path (UE AS -UE); or 

• scenario 2: two (or more) users communicating with (at least) one AS in the signalling and media path 
(UE-AS/MRFC-UE); or 

• scenario 3: two users communicate and one of the users is connected to PSTN/ISDN (UE-MGCF). This 
scenario can be seen as part of basic communication and requires no SIP signalling; or 

• scenario 4: two users communicate directly with each other without involving an AS in the signalling path and 
without involving an AS in the media path (UE-UE). This scenario is out of scope of the present document. 

A.2.1 Scenario 1:UE- AS -UE 

Two users are communicating with (at least) one AS in the signalling path. In this scenario the AS is connected to the 
S-CSCF over the ISC interface acting as a SIP proxy or an AS performing 3^*^ party call control. 

RFC 3261 [4] specifies the Call-Info header field as a means to indicate a source of media to be played by the receiving 
endpoint. 
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Figure A.5 shows an example of the use of this mechanism in the INVITE request. 
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NOTE: Some signalling details are left out of the figure for simplicity. 

Figure A.5: Call-Info header field in a re-INVITE request to indicate media 

A user wants to place a communication session on hold and sends a re-INVITE request towards the remote user 
involved in the communication. 

The steps of the flow are as follows: 

1) S-CSCF receives a re-INVITE from a user. The user can be a user served by this S-CSCF, a user served 
by another S-CSCF or a user connected to the PSTN via MGCF. 

2) S-CSCF sends the re-INVITE request along the signalling path to the AS using the route set received in 
the re-INVITE request. 

3) Service logic in the AS decides to include a reference to a wav file with an announcement or music. 

4) The AS sends the re-INVITE request to the S-CSCF. including in the Call-Info header a URL to a 
media file containing the appropriate announcement or music, for example 

http ://operator. net/announcement. wav (in the picture abbreviated to http://url.wav) . 
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5) The S-CSCF sends the re-INVITE request along the signalling path towards the remote user. The 

remote user may be a user served by this S-CSCF, a user served by another S-CSCF or a user connected 
to the PSTN via MGCF. 

6-9) The 200 (OK) response from the remote user is forwarded via the S-CSCF and the AS towards the 

originating user. 

10-13) The ACK request from the originating user is forwarded via the S-CSCF and the AS towards the remote 

user. 

14) The http://url.wav file is retrieved and played to the user. In the case the user is connected to the PSTN 

via a MGCF, the T-MGF retrieves and plays the announcement towards the user. In case the user is 
connected to IMS the UE retrieves and plays the announcement. 

A.2.2 Scenario 2: UE - AS/MRFC/MRFP - UE 

This clause describes the scenario when two (or more) users are communicating with (at least) one AS controlling the 
media path. The MRFP is in the media path. In this scenario the AS acts as a B2BUA. 

Figure A. 6 shows the signalling flow for the scenario. 
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Figure A.6: In-band announcement during an established communication 

An AS, acting as a B2BUA, is involved in a communication session. The AS controls the media path via a co-located 
MRFC controlling a MRFP. 
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The steps of the flow are as follows: 

1) Service logic in the AS decides to start an in-band announcement towards a user e.g. "Music on hold". 

2) The AS using the co-located MRFC interacts with the MRP in order to reserve resources for the 
announcement. 

3) The MRFC co-located with the AS interacts with the MRFP in order to start the announcement. 

4) The MRFP sends the announcement towards the remote user. 

5) The MRFC co-located with the AS interacts with the MRFP to stop the announcement. 

A.3 Communication request rejected 

Service logic in an AS, e.g. the ACR service, may decide to reject a communication request and provide an 
announcement to explain the reason for the rejection to the originating user. The AS can: 

1) Send the announcement as in-band information. 

2) Include a reference to the announcement in a 3xx, 4xx, 5xx and 6xx response. 

A.3.1 Sending the announcement as in-band information 

The network may generate announcement using one of the following procedures: 

1) using early media i.e. the AS establish an early session and uses that early session to send the in-band 
announcement; or 

2) using an established session i.e. the AS accepts the INVITE request and uses the established session to send 
the in-band announcement. 



A.3.1 .1 Using early media 



This clause explains how an AS can use an early media session to send the in-band announcement and when the 
announcement is sent reject the communication request with an appropriate reject code. 
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Figure A. 7 shows the signalHng flow for the scenario. 
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Figure A.7: Using early media to send in-band announcement 
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The originating user initiates communication by means of an INVITE request. A long the path towards the terminating 
user an AS determines that the INVITE request cannot be forwarded to the terminating user. The steps of the flow are 
as follows: 

1) S-CSCF receives an INVITE request from the originating user. The originating user may be a user served by 
this S-CSCF, a user served by another S-CSCF or a user connected to PSTN/ISDN via a MGCF. 

2) S-CSCF sends a 100 (Trying) response. 

3) S-CSCF evaluates the Initial Filter Criteria. 

4) S-CSCF sends the INVITE request to the AS. 

5) The AS sends a 100 (Trying) response to S-CSCF. 

6) Service logic in the AS decides to reject the communication request and to send an announcement in-band in 
order to give a detailed reason to the originating user. 

7) The MRFC collocated with the AS interact with the MRFP and reserves resources for the announcement. 

8) The AS sends a 183 (Session progress) response to S-CSCF. 
The response includes: 

a) the Require header field with the option-tag " lOOrel" ; and 

b) an answer to the SDP received in the INVITE request; 

c) a P-Early-Media header field set to "sendonly". 

9) S-CSCF sends the 183 (Session Progress) response towards the originating user. 

10) The MRFC collocated with the AS interact with the MRFP in order to start the announcement. 

11) S-CSCF receives a PRACK request from the originating user. 

12) S-CSCF sends the PRACK request to the AS. 

13) The AS sends the 200 (OK) response to the PRACK request to S-CSCF. 

14) S-CSCF sends the 200 (OK) response to the PRACK request to the originating user. 

15) MRFP sends the announcement towards the UE. 

16) The MRFP interacts with the MRFC collocated with the AS to indicate that the announcement is sent. 
17 



18 
19 
20 
21 



The MRFC collocated with the AS interact with the MRFP in order to release resources reserved for the 
announcement. 

The AS sends a 487 response to the INVITE request to S-CSCF. 

S-CSCF sends an ACK request to the AS. 

S-CSCF sends a 487 response to the INVITE request to the originating user. 

S-CSCF receives an ACK request from the originating user. 



A.3.1 .2 Using an established session 



This clause explains how an AS can use an established session to send the in-band announcement and when the 
announcement is sent, release the communication and include an appropriate reject code in the BYE request. 
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Figure A. 8 shows the signalHng flow for the scenario. 
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Figure A.8: In-band information generated by network when 
an invitation to a communication is rejected 
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The originating user initiates communication by means of an INVITE request. A long the path towards the terminating 
user an AS determines that the INVITE request cannot be forwarded to the terminating user. 

The steps are as follows: 

1) S-CSCF receives an INVITE request from the originating user. The originating user may be a user served by 
this S-CSCF, a user served by another S-CSCF or a user connected to PSTN/ISDN via a MGCF. 

2) S-CSCF sends a 100 (Trying) response. 

3) S-CSCF evaluates the Initial Filter Criteria. 

4) S-CSCF sends the INVITE request to the AS. 

5) The AS sends a 100 (Trying) response to S-CSCF. 

6) The AS decides to reject the communication request and to send an announcement in-band in order to give a 
detailed reason to the originating user. 

7) The MRFC collocated with the AS interact with the MRFP and reserves resources for the announcement. 

8) The AS sends a 200 (OK) response to the INVITE request to S-CSCF. 

9) S-CSCF sends the 200 (OK) response to the INVITE request towards the originating user. 

10) The MRFC collocated with the AS interact with the MRFP in order to start the announcement. 

11) S-CSCF receives an ACK request from the originating user. 

12) S-CSCF sends the ACK request to the AS. 

13) MRFP sends the announcement towards the originating user. 

14) The MRFP interacts with the MRFC collocated with the AS to indicate that the announcement is sent. 

15) The MRFC collocated with the AS interact with the MRFP in order to release resources reserved for the 
announcement. 

16) The AS sends a BYE request to S-CSCF. The BYE request may include an appropriate reject reason. 

17) S-CSCF sends the BYE request towards the originating user. 

18) S-CSCF receives a 200 (OK) response to the BYE request from the originating user. 

19) S-CSCF sends the 200 (OK) response to the BYE request to the AS. 

A.3.2 Including an Error-Info header field in a 3xx, 4xx, 5xx and 
6xx response 

This clause explains how an AS can include a reference to an announcement stored in the network. 

IETF defines an Error-Info header field for use in 3xx, 4xx, 5xx and 6xx responses to the INVITE request. The 
Error-Info header field transports a reference to a file e.g. a file containing an announcement. 

When the originating UE receives the reference the UE retrieves the announcement and plays it for the user. 
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Figure A. 9 shows the message flow for the scenario. 
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Figure A.9: Error-Info header in 3xx, 4xx, 5xx and 6xx responses 

The originating user initiates communication by means of an INVITE request. A long the path towards the terminating 
user an AS determines that the INVITE request cannot be forwarded to the terminating user. 

The steps are as follows: 

1) S-CSCF receives an INVITE request from the originating user (in the case the AS is an 0-AS) or the 
originating network (in the case the AS is a T-AS). 

2) S-CSCF sends a 100 (Trying) response. 

3) S-CSCF evaluates the Initial Filter Criteria. 

4) S-CSCF sends the INVITE request to the AS. 

5) The AS sends a 100 (Trying) response to S-CSCF. 

6) The AS decides to reject the invitation to communication and to provide a reference to an announcement 
explaining the reason in more detail. 

7) The AS sends a 3xx, 4xx, 5xx or 6xx response to S-CSCF. The application server inserts a valid Error-Info 
header field in either a 3xx, 4xx, 5xx or 6xx response to the INVITE request, including a URL to a media file 
containing the appropriate tone, announcement or music. 

EXAMPLE: http://operator.net/announcement.wav , in the picture abbreviated to http://url.wav , is played at the 
originating UE (after step 10). 

8) S-CSCF sends the ACK request to the AS. 

9) S-CSCF sends the 3xx, 4xx, 5xx or 6xx response towards the originating user. 

10) S-CSCF receives the ACK request. 
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A.3.3 Announcements provided by the PSTN/ISDN 

The signalling flow for this scenario is the same as the signalling flow example given in clause A. 1.3. 

A.3.4 Announcement provided to a user connected to tine 
PSTN/ISDN 

The signalling flow for this scenario is the same as the signalling flow example given in clause A. 1.4. 

A.4 Providing announcements to a user during the 
release of a comnnunication session 

The way an announcement is sent to a user during the release of a communication depends on the scenario. 
The following scenarios exist: 

• scenario 1: two users are communicating with (at least) one AS in the signalling path (UE-AS-UE); or 

• scenario 2: two (or more) users communicating with (at least) one AS in the signalling path and MRFP in the 
media path (UE-AS/MRFC/MRFP-UE). 
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A.4.1 Scenario 1:UE- AS -UE 

Two users are communicating with (at least) one AS in the signalHng path. 
Figure A. 10 shows the signalHng flow for the scenario. 
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NOTE: The party still in the communication may return provisional responses to the INVITE request. However, for 
simplicity those responses are left out. 

Figure A.10: Play announcement using new media during the release of a communication 

The steps of the signalHng flow are as follows: 

1) S-CSCF receives a BYE request. 

2) S-CSCF sends the BYE request to the AS. 

3) Service logic in the AS decides to send an announcement to the party still in the communication. 

4) The MRFC interacts with the MRFP in order to reserve resources for the announcement. As part of the 
interaction with MRFP, the AS retrieves the media parameters from MRFP e.g. IP address and port numbers, 
and provide the IP address and port numbers of media that original dialog used to the party still in the 
communication. 
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5) The AS sends a re-INVITE request to S-CSCF. 

6) S-CSCF sends the re-INVITE request towards the party still in the communication. 

7) S-CSCF receives a 200 (OK) response. 

8) S-CSCF sends the 200 (OK) response to the AS. 

9) The AS sends an ACK request to S-CSCF. 

10) S-CSCF sends the ACK request to the party still in the communication. 

11) The MRFC interacts with the MRFP in order to start the alternative ring tone. 

12) The MRFP sends the announcement towards the party still in the communication. 

13) The complete announcement is sent and the MRFP interacts with the AS/MRFC in order to inform that the 
announcement is terminated. 

14) The MRFC interacts with the MRFP in order to release the resources used for the announcement. 

15) The AS sends the BYE request to S-CSCF. The BYE request contains the same information as the BYE 
request received in step 2 with the modification done by AS according to rules and procedures of DES 
TISPAN-ES 283 003 [1]. 

16) S-CSCF sends the BYE request towards the party still in the communication. 
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A.4.2 Scenario 2: UE - AS/MRFC/MRFP - UE 

This clause describes the scenario when two (or more) users are communicating with (at least) one AS controlling the 
media path. The MRFP is in the media path. In this scenario the AS acts as a B2BUA. 

Figure A. 11 shows the signalling flow for the scenario. 
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Figure A.1 1 : Play announcement using exist media during the release of a communication 

The steps of the signalling flow are as follows: 

1) The AS receives a BYE request. 

2) Service logic in the AS decides to start an in-band announcement towards a user. 

3) The AS using the co-located MRFC interacts with the MRP in order to reserve resources for the 
announcement. 

4) The MRFC co-located with the AS interacts with the MRFP in order to start the announcement. 

5) The MRFP sends the announcement towards the remote user. 

6) The MRFC co-located with the AS interacts with the MRFP to stop the announcement. 

The AS sends the BYE request towards the remote user. The BYE request contains the same information as the BYE 
request received in step 1 with the modification done by AS according to rules and procedures of ES 283 003 [1]. 
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Annex B (informative): 

Signalling flows for Network Determined User Busy (NDUB) 

B.1 Basic call with UE busy with T-AS involvement 
(NDUB condition check) 

This clause describes the signalling flow for the case when the user is busy but the network does not consider the user to 
be busy. 

Figure B.l shows the signalling flow for the scenario. 
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NOTE: The signalling flow is simplified for readability reasons. 

Figure B.1 : Basic call with UE busy with T-AS involvement (NDUB condition check) 

This signalling flow assumes the following: 

• the user in the terminating network needs the involvement of an AS for NDUB or other busy condition 
activated services like CCBS or CFBS; and 

• the filter criteria are set for basic communication accordingly. 

NOTE: The same scenario applies also for other error responses e.g. for the 403 (Service Denied) response, the 
480 (Temporarily Unavailable) response. 
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The steps of the flow are as follows: 

1) The S-CSCF serving the terminating user receives an INVITE request from the originating network. The 
originating network may be a TISPAN IMS network, a PSTN/ISDN Emulation network, another SIP based 
network or a MGCF interworking with PSTN/ISDN. 

2) The S-CSCF checks the IFC and finds that a trigger fires and sends the INVITE request to the AS. The address 
to the AS is obtained from the IFC. 

3) The AS checks the busy condition and it is not NDUB and sends the INVITE request to the S-CSCF. 

4) The S-CSCF sends the INVITE request according to the P-CSCF. 

5) The P-CSCF sends the INVITE request according to the UE#2. 

6) The UE#2 is e.g. involved in another communication and determines itself to be busy and sends a 486 
(Busy here) response to the P-CSCF. 

7) The 486 (Busy here) response to originating network via the S-CSCF and the AS. 



B.2 Busy condition (NDUB) detected by terminating AS 

This clause shows an example of a signalling flow when a terminating network determines the user to be busy i.e. the 
NDUB case. 

Figure B.2 shows the signalling flow for the scenario. 



Originating network 



Terminating network 



S-CSCF 



-1. INVITE- 



-4. 486 Busy here- 



T-AS 



-2. INVITE- 



AS checks busy 

condition NDUB 

detected 



-3. 486 Busy here- 



NOTE: The signalling flow is simplified for readability reasons. 

Figure B.2: Busy condition (NDUB) detected by terminating AS 

This signalling flow assumes the following: 

• the user in the terminating network needs the involvement of AS for NDUB or other busy condition activated 
services like CCBS or CFBS; and 

• that the filter criteria are set for basic communication accordingly. 
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The steps of the flow are as follows: 



1) The S-CSCF serving the terminating user receives an INVITE request from the originating network. The 
originating network may be a TISPAN IMS network, a PSTN/ISDN Emulation network, another SIP based 
network or a MGCF interworking with PSTN/ISDN. 

2) The S-CSCF checks the IFC and finds that a trigger fires and sends the INVITE request to the AS. The address 
to the AS is obtained from the IFC. 

3) The AS checks the busy condition and detects that it is NDUB and sends a 486 (Busy here) response to the 
S-CSCF. 

4) The AS sends the 486 (Busy here) response to the originating network via the S-CSCF. 

5) The S-CSCF sends the 486 (Busy here) response to the originating network. 
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Annex C (normative): 
Void 
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Annex D (normative): 

Application Server (AS) establishing multiple dialogs with 

originating UE 



D.1 General 



If the AS needs to establish an early dialog between itself and the originating UE (or originating network), for example 
in order to establish a media path in order to send announcements or other kind of early media backwards, it shall do so 
by sending a provisional response towards the originating UE. The setup procedures between the originating UE and the 
AS are identical to normal setup procedures. 

The To header tag value in the dialog between the originating UE and the AS shall, in order to separate the dialogs, be 
different than the To header tag value in messages used on the dialog used between the originating and terminating 
UEs. The AS normally receives the To header tag value for the dialog between the UEs from the terminating UE (or the 
terminating network), but if the AS acts as a B2BUA it may also, depending on the functionality, generate a new 
To header value. 

The need for the AS to establish an early dialog between itself and the originating UE is determined on the services 
offered to the originating UE. 

NOTE 1 : Unless the originating UE can determine that the messages sent on the early dialog between itself and the 
AS are originated from the AS, it will assume that forking has occurred in the network. 

NOTE 2: If the originating UE has indicated that it does not want the initial INVITE to be forked, the AS may still 
establish a separate early dialog between itself and the originating UE, since even though the originating 
UE may assume that the call has been forked only one terminating UE will actually receive the INVITE 
request. 

NOTE 3: Once the originating UE has received 200 (OK) from the terminating UE the early dialog between the 
originating UE and the AS will be terminated, as described in RFC 3261 [4]. 
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Annex E (informative): 

Signalling flows for 3"^^ party call control 

The following signalling flows provide examples for the Spec procedures described in clause 4.7.2.9.7. 
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Figure E.1 : Example flow for REFER interworking with REFER sent 
inside a dialog with usage of a media server 
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Figure E.2: Example flow for REFER interworking with REFER sent 
outside a dialog with usage of a media server 
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Figure E.3: Example flow for REFER interworking in case of 
No Reply with usage of a media server 



ETSI 



47 



ETSI TS 183 028 V2.4.0 (2008-01) 



-Dialog 1a- 
-Dialog 2a- 



Media Server (MS) 



• Dialog 2b- 



REFER B 

From: A 

To: B 

Call-ID: Dialog 1a 

Refer-to: C?Replaces=Dialog2a 

(method=INVITE) 



202 Accepted 



NOTIFY/ 200 OK 
Call-ID: Dialog la 
(100 Trying, Dialog 1b) 



re-INVITEA 
200 OK 



REFER B 
REFER B 



---'Dialog lb ---- 



RTPIb 

HOLD 

announcement 



403 Forbidden 



re-INVITE A 

From: B 

To: A 

Call-ID: Dialog la 

P-Asserted-ID: B 

o = MS 

a = inactive 

200 OK 



re-INVITE C 
From: B 
To:C 
»Call-ID: Dialog 2b 
P-Asserted-ID: B 
m = Codec from dialog 1 b 
= MS (Announcement) 

200 OK I 

I ACK 



re-INVITE B 
From: C 
To:B 

Call-ID: Dialog lb 
P-Asserted-ID: C 
Referred-by: A 
m = Codec lb 
= MS (Through-connectt 
re-INVITE E 

I 200 OK 



|B-Channel^ 



in case B is not on Hold A 
needs to be conected to an 
Announcment and also a 

re-INVITE to B is needed, 
m = Codec from dialog 1 b 

o = MS (Announcement) 



• Dialog 2b-- 
RTP2b- 



----Dialog 1a---- 

NOTIFY/200OK 
Call-ID: Dialog la 
(200 OK, Dialog 1b) 



BYE 
Call-ID: Dialog 2a 



'---'Dialog lb --- 

4 RTP lb > 



— ► 

^B-Channel^ 



Figure E.4: Example flow for REFER interworking in case the Refer-to header field 
contains a replaces parameter with usage of a media server 
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-Dialog 1a- 



REFER B 

From: A 

To: B 

Call-ID: Dialog 1a 

Refer-to: C 

(method= INVITE) 



202 Accepted 



NOTIFY 
200 OK 



INVITE C 

200 OK 

From: B 

To: C 

Call-ID: Dialog 2b 

m = Codec 2b 

= UE-C 



re-INVITEA 
200 OK 



REFER B 
REFER B 



----'Dialog lb ---- 



— REFER B 

403 Forbidden 



NOTIFY 

Call-ID: Dialog la 
(100 Trying, Dialog 1b) 



INVITE C 

From: B 

To: C 

Call-ID: Dialog 2b 

P-Asserted-ID: B 

no SDP 



200 OK I 

re-INVITE B 

From: C 

To:B 

Call-ID: Dialog lb 

P-Asserted-ID: C 

Referred-by: A 

m = media types from 1 b 

= UE-C 



— ► 

^B-Channel^ 



In case B is not on Hold any 
time a BYE is received from A 
before the 200 OK to the INVITE 
to C, a re-INVITE to B is needed, 
m = Codec from dialog 1b 
= 0.0.0.0 



re-INVITE B 
200 OK 



re-INVITE A 

From: B 

To: A 

Call-ID: Dialog la 

P-Asserted-ID: B 

m = Codec la 

= 0.0.0.0 

200 OK 

ACK 



• Dialog 2b- 



-Dialog la- 



NOTIFY 
200 OK 



NOTIFY 

Call-ID: Dialog la 
(200 OK, Dialog lb) 



----'Dialog lb ---- 



— > 

4B-Channel^ 



Figure E.5: Example flow for REFER interworking with REFER sent inside a dialog 

without usage of a media server 
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